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InterBase vs. Paradox 


Which Is Best for Your Application? 


: f you’re like me, when you first bought Delphi you didn’t pay much 


attention to the Local InterBase Server bundled in the package. Most 


likely, even if you were learning to build database applications, you 


amused yourself for weeks using nothing but Paradox tables. In fact, like 


me, you may have came from a Paradox background. 


The products are so strongly associated that 
many people have had difficulty making the 
distinction. And rumors that Delphi would 
replace Paradox compounded the problem. 
Although it should be clear by now that this 
isnt the case, most developers still use Paradox 
tables for their Delphi database development. 
In short, I doubt many bought Delphi to get 
their hands on the Local InterBase Server. 


Piqued Curiosity 

But, programmers are a naturally curious lot, 
and many of them eventually began poking 
at Local InterBase. At first glance, it doesn't 
seem that different from Paradox. You access 
it using an alias, just as Paradox, and 
although they have different names, the field 
types are similar. You can even create 
InterBase tables using the Database Desktop. 
You use the same 77able and TQuery com- 
ponents that are used for Paradox tables. In 
short, the Borland Database Engine (BDE) 
interface creates a convincing illusion that 
InterBase tables behave like Paradox tables. 


Except InterBase is supposed to be better some- 
how. It’s an industrial-strength RDBMS, so it 
must be bigger and faster that Paradox, right? 


For many developers, though, disillusionment 
soon sets in. After creating InterBase tables with 
the Database Desktop, they discover they can’t 
casually change field definitions by simply 
restructuring as they can with Paradox tables. 
All searches and indexes are case-sensitive, 
unlike Paradox. Defining primary and foreign 


keys seems easy, but changing them seems near- 


ly impossible. Worst of all, some operations are 
slower with InterBase than with Paradox. It 
quickly becomes apparent that InterBase isn’t 
automatically better than Paradox. 


The idea that InterBase isn’t better than 
Paradox is absolutely true. At least, it’s not 
always better. The two products are significant- 
ly different, and are intended to serve in differ- 
ent situations. The only thing they really have 
in common is that they both store data in 


tables. They diverge rapidly from that point. 


Each is a system with strengths and weak- 
nesses. The trick is deciding which is appro- 
priate for a particular application. And once 
made, that decision fundamentally affects the 
subsequent development effort. 


Paradox Is File Based 

Paradox is a file-based database system. The 
data files contain data records that have a defi- 
nite order. In other words, record number 106 
will always be the same record until it’s physi- 
cally moved within the file, perhaps as a result 
of a sorting operation. Even more importantly, 
it will always follow record 105 and precede 
record 107, until that order is explicitly 
changed. This allows the records to be easily 
navigated by a cursor, since it’s possible to iden- 
tify a record by its position within a table with- 
out having to reference the data it contains. 


This explicit physical ordering of records has 
some advantages. Moving back and forth 
through the data file is a simple matter, and 
the records are easily refreshed when the cur- 
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sor arrives at them. The concept of browsing is convenient for 
users and developers. It allows records to be handled one at a 
time, in a predictable order. This navigational behavior is one 
of the major Paradox concepts that is difficult to transplant 
into the InterBase world, and many Paradox developers have 
a difficult time making the transition. 


InterBase Is Set Based 

InterBase is a true, set-based relational database system. 
Tables aren't stored in individual files. More importantly, the 
records are not ordered. Mathematically speaking, sets are 
unordered. Order is “discovered” only when the set is physi- 
cally represented, such as when querying a database. You can’t 
count on the same record being record number 105 twice in 
a row, unless you explicitly impose a certain ordering on the 
query. Since you can’t positively identify a record by its posi- 
tion within the table, you must refer to values within the 
record. Therefore, to positively identify a record, at least one 
field or combination of fields must contain unique values for 
each record. This is what’s known as a primary key. 


It’s possible for more than one field or combination to pro- 
vide unique values, in which case they form a pool of candi- 
date keys. Since it’s important for a database management sys- 
tem to identify individual records conclusively, the existence 
of a primary key is crucial. A table that has a unique primary 
key is called an R-table, and all data sets must be R-tables for 
the relational model to work. 


The advantage of this set-based conceptualization of data is 
that sets and the operations that can be performed on them 
have the property of closure. This means that when you per- 
form a set operation on a set, it always produces another set, 
which can then have another operation performed on it, 
producing another set, ad infinitum. This is a powerful logi- 
cal concept, and if it’s properly implemented, will remove 
the physical characteristics of storage from consideration in 
the application’s design. This is the foundation of the rela- 
tional model. 


Cursor-based systems such as Paradox allow you to work only 
on one record at a time, repeating an operation when you 
want to process groups of records. Set-based systems allow you 
to manipulate a set of data as if it were a single entity, all com- 
ponents of which will share the same fate. This has the poten- 
tial of increasing the simplicity of application design and vast- 
ly improving data integrity. 


Strangely enough, the ANSI SQL specification, which pur- 
ports to be a relational standard, doesn’t require a primary 
key to be defined for each table. This means records within 
the data sets that are produced by SQL queries don't have to 
be uniquely identified by value. 


Even worse, the results of SQL queries, even if they come 
from proper R-tables, don’t have to be R-tables themselves. 
Because identification by value is the only reliable method of 
identifying individual records within a set, the primary key is 


a fundamental cornerstone of the relational model, and its 
absence causes significant problems. 


You will quickly discover how this rather incomprehensi- 
ble omission by the ANSI committee will cause you prob- 
lems while using Delphi and the BDE to develop SQL 
applications — unless you exercise the discipline to ensure 
that your queries always return correct R-tables. (We'll 
comprehensively cover the full implications of this in a 
future article.) 


Physical Design and Its Impact on Speed 

Paradox is a client-based system where the data is completely 
managed by the individual clients. Whenever data must be 
read or manipulated in any way, it must be transported to the 
Paradox application. Each application handles all processing 
itself. If multiple users are accessing data simultaneously on a 
network, each user's application transports the data it requires 
back to the user’s machine. 


Each instance of Paradox has no regard for the others. If an 
instance of Paradox needs to guarantee the stability of data 
for any reason, it must forcibly prohibit other instances from 
changing the data through a locking scheme. 


When a Paradox application needs to search a table, the 
necessary raw data and indexes must be loaded into the 
client machine’s memory, the physical activity of the search 
conducted, results produced, and the now-unneeded raw 
data discarded. This activity is repeated for every operation 
on every client. The file server holding the data files does 
absolutely nothing more than send the requested raw data 
over the network to the client machines, making absolutely 
no attempt to process the data. In essence, it acts as a 
remote hard disk. 


What this usually means is that Paradox is speedy on a local 
hard drive, but slows down dramatically over a network. 
Network bandwidth can quickly become clogged with large 
volumes of unprocessed data being shipped repeatedly to the 
client machines. Even in a fairly small network environment, 
performance degrades rapidly as new users arrive. 


InterBase is a server-based system. Instead of different 
processes physically manipulating the stored data, only one 
central process running on the server machine has direct 
access to the data. All the client applications make polite 
requests to the server process, which does the actual process- 
ing entirely on the server machine while the client waits. 


When the server finishes, it passes only the result back to 
the client, which then goes on about its business. The 
most direct impact of this scheme is that the network 
doesn't need to be clogged with large volumes of redun- 
dant raw data being sent to the clients. Also, the often 
complex data processing tasks can be delegated from usu- 
ally less powerful client machines to the usually more 
powerful server machine. 
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Notice that everything about InterBase’s design implies a 
multi-user environment. InterBase was designed from the 
ground up as a multi-user system. Paradox, on the other 
hand, was designed primarily for a single user, with support 
for multi-user capabilities added on. 


InterBase Isn't for Browsing 

As mentioned earlier, despite the fact that InterBase is a true 
RDBMS, it performs some operations more slowly than does 
Paradox. For the most part, these are browsing operations — 
natural for Paradox — that the BDE is attempting to emu- 
late with InterBase. The problem is most obvious if you have 
a rather large table, perhaps 100,000 records, attached to a 

T Table. If you call the T7able’s Last method, attempting to 
move the record pointer to the last record, the performance 
of the two systems will vary wildly. 


The Paradox table’s cursor will move almost instantly 
because it knows the physical location of the last record in 
the data file and can simply increment the file pointer to 
that location and retrieve the data. The InterBase table, 
however, is going to present some problems. First, because 
the data is unordered, there is some question about what 
constitutes “lastness.” It must impose an order before it 
can decide which record is “last.” By default, the last 
record will be considered to be the record whose primary 
key has the greatest value. 


It’s now necessary to determine the value of the maximum 
primary key. Once that value has been determined, the 
record matching that value can be retrieved. However, if the 
last few records must be retrieved, as would be the case in a 


grid display, the process has to be repeated. 


Now, InterBase must find the greatest primary key value that is 
less than the maximum primary key value. For the third, it 
needs the next-to-next-greatest primary key value, and so forth 
until the required number of records is found. An operation 
that is a piece of cake for Paradox is a major pain for InterBase. 
In general, attempting to navigate backwards through SQL 
tables is inefficient. The BDE buffers groups of records to min- 
imize this problem, but if you go backwards far enough, you'll 
have to pause for significant amounts of time in large tables. 


Locking 

Whenever two users attempt to change the same piece of data, 
problems can arise that threaten the integrity of the database. 
Paradox and InterBase address this problem in different ways. 


Because Paradox has no direct knowledge of what other 
Paradox processes are doing, it uses a pesszmistic locking 
scheme. As soon as a user attempts to change a record, the 
record is locked. No other user can change the record until 
the first user finishes editing, or cancels the changes. This is 
good, in that a user who successfully obtains a lock can defi- 
nitely complete the editing operation. It’s also bad, because a 
user can monopolize a record indefinitely. This would be a 
problem, for example, in a travel reservation system. An inde- 


cisive traveler can lock down a seat for a long time, causing 
others to believe the seat is taken, only to decide not to take 
the seat after all. 


InterBase, on the other hand, handles all data manipulation 
by itself using an optimistic concurrency scheme. It’s therefore 
in a better position to manage contention among users with- 
out resorting to Draconian locking tactics. The fact that one 
user may be in the process of changing a record will not pre- 
vent other users from also attempting to change it. Whenever 
a user begins to change a record, InterBase saves a copy of the 
original record. The user goes about his or her business, but 
other users are not prohibited from accessing the same record 
in any way. 


When the editing user posts the changes, the original copy is 
compared to the current record. If the versions are different 
(most likely because another user beat them to the punch) 
the user’s changes are rejected. 


What this means is that individual users can’t lock others out 
of records. In the above travel reservation scenario, the first 
traveler to commit a reservation gets the seat, even if several 
were considering it simultaneously. The downside, of course, 
is that the changes are not rejected until the record is posted, 
after the work of editing has been done. This can be mitigat- 
ed, however, by refreshing the changed fields and resubmit- 
ting. 7 7able and TQuery do this transparently, for example, 
using the UpdateMode property. The post can be resubmitted 
if all fields match the originals, only the changed fields 
match, or only the primary key matches, whichever is appro- 
priate to ensure integrity. 


The two approaches reflect a basic difference in philosophy. 
The Paradox pessimistic model assumes that collisions will 
be common, and gives strong control of the record to who- 
ever seizes it first. The optimistic InterBase model assumes 
that collisions will be rare, and maximizes the ability of users 
to share data without interfering with one another, while 
still maintaining integrity. 


An important benefit of the InterBase model is that one 
user who wants to see a stable data set, perhaps to generate 
a series of reports that need to reflect the same snapshot of 
data, will not interfere with other users who want to change 
the same data. In Paradox, the report generator would have 
to place a write lock on the table to guarantee the data will 
not change, and nobody can update data in that table as 
long as the lock exists. 


In InterBase, old versions of records are retained as long as a 
user is interested in them — so, other users do not have to be 
prevented from updating the records. This means that in 
InterBase, readers never prevent writers from succeeding, nor do 
writers compromise the results of readers. InterBase is the only 
SQL database that does this so transparently. When InterBase 
proponents are asked what the advantages of InterBase are, this 
record versioning is usually the first thing they mention. 
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Transaction Processing 

As youll recall, a basic premise of the set-based model is that sets 
of data can be treated as individual entities, regardless of the set’s 
specific contents. Transaction processing is an extension of this 
idea. A transaction is a group of operations that must either all 
succeed or all fail. It's never acceptable only for some to succeed. 


For example, your automated teller machine (ATM) performs 
database transactions. Whenever you withdraw cash, two 
operations must be performed for the bank to properly 
account for its assets: The balance of your account must be 
reduced, and the balance of cash on hand must also be 
reduced by the same amount. Obviously, the preferred situa- 
tion is for both operations to succeed, but if the power goes 
off in the middle of the operation, it’s absolutely not accept- 
able for one account to be updated and not the other — 
both operations must fail to maintain the proper accounting. 


Transaction processing allows this to happen. The operations 
in a transaction are not permanent until the whole transac- 
tion is committed. Until that time, it may be rolled back to 
the starting point. A rollback can be explicitly triggered using 
the Rollback method, or it can occur automatically when a 
system failure occurs. 


InterBase fully supports transactions. In fact, all operations 
occur within the context of a transaction. In the absence of 
explicit programmer control, the BDE automatically “wraps” 
every operation in its own transaction. For example, every 
time you post a record, a transaction is started and committed 
immediately after the post. Using the 7Database component, 
you can explicitly control a single transaction and have it 
encompass as many operations as you like. 


However, the BDE does not fully support InterBase’s transac- 
tion capabilities. Database methods can only be used against 
a single InterBase database, and only one transaction may 
exist at a time for each BDE alias. InterBase itself supports 
multiple simultaneous transactions per connection, and a 
transaction can also encompass more than one database, but 
the BDE doesn’t surface these abilities. You'll have to make 
calls to the InterBase API to use these features. 


Paradox doesn't support transactions. Whenever a record is post- 
ed, the changes are permanently written to the table. It requires 
another edit to manually change it back if a rollback is desired. 
In addition, the system will not guarantee that a group of opera- 
tions will all either succeed or all fail. It's possible to simulate 
some of this capability through some tricky programming and 
temporary tables, but eventually the records must be modified 
one at a time in a batch, which leaves a window for failure. And 
there's no way you can program a Paradox application to recover 
from a system failure such as a power outage or disk crash. 


Triggers and Procedures 

A stored procedure is a piece of code that is stored in the 
database along with the data. It allows the server to per- 
form complex manipulation of data entirely on the server. 


The main advantages are that even more complex process- 
ing can be delegated to the server, and any number of dif- 
ferent client applications can call the same procedures. If 
the procedure is modified on the server, none of the appli- 
cations has to be rewritten as long as the procedure’s inter- 
face remains the same. 


A trigger is short for triggered procedure. It’s a stored proce- 
dure that is not explicitly called by an application, but is exe- 
cuted in response to a data action, such as inserting a new 
record. Triggers allow you to perform extremely complex data 
validation, and are guaranteed to execute within the same 
transaction that performed the triggering operation. If any 
operation fails, all changes made by triggers associated with 
that operation are also rolled back. 


InterBase supports stored procedures that return result 
sets, which can be treated exactly as read-only tables, as 
well as triggers that simply perform data transformations 
and don’t return any results. It supports essentially unlim- 
ited numbers of triggers for each table, which can occur 
before or after inserts, updates, and deletes. If more than 
one trigger is associated with an operation, their order of 
execution can be specified. Triggers can make changes that 
execute other triggers, in a chain-reaction fashion, but all 
such cascading actions are still contained within a single 
transaction. 


Paradox does not support either of these concepts. All data 
processing must be done at the client. Each application must 
contain the same code to maintain the data, and each appli- 
cation must be modified if the method of handling data 
must be changed. 


There is no guarantee that an operation will be completed 
once it’s started. For example, cascading the delete of a 
master record to its detail records can fail in midstream, 
leaving details undeleted. If this cascade were implemented 
as a trigger in InterBase, either all or none of the records 
would be deleted. Furthermore, the code to cascade the 
delete must be written into each different application that 
uses the Paradox data. Using InterBase, it only needs to be 
written once in a trigger. The application simply deletes 
the master record and InterBase takes care of deleting the 
detail records. 


Making the Choice 

Choosing between Paradox and InterBase has important 
implications for your project. Accordingly, it’s essential to 
know what is important for your situation. Figure 1 shows 
some general principles that can help you make a decision. 


These are guidelines, not rules. Most of them assume a net- 
work is involved. If you are contemplating a single-user system, 
Paradox is usually the best choice. The Local InterBase Server 
can be deployed as a single-user system, but without concur- 
rency issues, many InterBase features don’t apply. If the ability 
to browse data is important, Paradox is also a good choice. 
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Paradox Is Better When ... | InterBase Is Better When ... 
Primarily used by fewer than Primarily used by more than 
10 concurrent users. 10 concurrent users. 

Data and data structures must Data should be centrally 
easily be modified by end-users. | maintained and protected. 
Client machines are compara- | Server is much more powerful 
ble in power to the server. than the clients. 


Plenty of network bandwidth. Network is loaded. 

Speed and convenience are Data integrity is crucial. 

more important than integrity. 

Little network and SQL Skilled network and database 
expertise is available. administrators are available. 
Only one application will Several applications may 
routinely access the data. access the data. 

Applications will be responsi- Database will enforce data 


ble for maintaining data integrity independently of 
integrity. applications. 


Small to moderate amounts Moderate to large amounts of 
of data (< 100MB). data (> 100MB). 


Figure 1: Comparing Paradox and InterBase. 


Conclusion 

It’s important to remember that Paradox and InterBase are 
substantially different systems, even though the BDE 
attempts to make them look similar. It’s a seductive, but dan- 
gerous idea that converting an application from one to the 
other involves nothing more than changing an alias. They 
require significantly different design concepts, and a design 
that is efficient with one will likely not be with the other. 
Selecting which system to use is a crucial decision that must 
be made at the start of a project. It will profoundly impact 
your subsequent development effort. A 


Kevin J. Bluck is an independent consultant based in Sacramento, CA. His specialty 
is database development with Borland products such as Delphi, Paradox, Borland 
(++, and InterBase. Kevin can be reached on CompuServe at 1034473510, or 
on the Internet at kevinbluck@aol.com. 
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